Techniques to strengthen one-time pad encryption

ABSTRACT

Apparati, methods, and computer-readable media for strengthening a one-time pad encryption system. A method embodiment of the present invention comprises the steps of encrypting plaintext ( 1 ) with an OTP key ( 2 ) in an XOR operation to produce ciphertext ( 3 ); and obfuscating the ciphertext ( 3 ) with an AutoKey ( 4 ) in an XOR operation to produce AutoKeyed ciphertext ( 5 ), wherein the AutoKey ( 4 ) is a reusable key.

RELATED PATENT APPLICATIONS

This patent application is a divisional of commonly-owned U.S. patentapplication Ser. No. 12/942,547 filed Nov. 9, 2010, which is acontinuation of commonly-owned U.S. patent application Ser. No.11/191,878 filed Jul. 28, 2005 (now U.S. Pat. No. 7,840,002 issued Nov.23, 2010), which patent application claims the priority benefit of U.S.provisional patent application 60/592,310, filed Jul. 29, 2004; allthree of these previous patent applications are hereby incorporated byreference in their entireties into the present patent application.

TECHNICAL FIELD

This invention pertains to the field of encryption systems using aone-time pad (OTP).

BACKGROUND ART

U.S. published patent application no. US 2004/0017917 A1, entitled“Cryptographic Key Distribution Using Key Folding,” published Jan. 29,2004, and U.S. published patent application no. US 2004/0136537 A1,entitled “Cryptography Key Distribution Using Key Unfolding,” publishedJul. 15, 2004, pertain to improving the distribution of keys used in aone-time pad encryption system. The present invention pertains tostrengthening the one-time pad encryption system itself.

DISCLOSURE OF INVENTION

Apparati, methods, and computer-readable media for strengthening aone-time pad encryption system. A method embodiment of the presentinvention comprises the steps of encrypting plaintext (1) with an OTPkey (2) in an XOR operation to produce ciphertext (3) ; and obfuscatingthe ciphertext (3) with an AutoKey (4) in an XOR operation to produceAutoKeyed ciphertext (5), wherein the AutoKey (4) is a reusable key.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other more detailed and specific objects and features of thepresent invention are more fully disclosed in the followingspecification, reference being had to the accompanying drawings, inwhich:

FIG. 1 is an illustration of a first application of AutoKey 4.

FIG. 2 is an illustration of a first application of KernelKey 6.

FIG. 3 is an illustration of a second application of KernelKey 6, aswell as a general illustration of the functioning of a one-time padencryption system.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Definitions

The following terms have the following meanings throughout the presentspecification, including claims.

“AK (AutoKey)” 4 means a reusable key that is used in an XOR operationin the manner described herein and for the purposes described herein.

“GUID (globally unique identifier)” 8 means a series of bits thatuniquely identifies an item, in this case a KernelKey 6.

“Key identifier” means a series of bits that identifies which key 2 outof a set of keys 2 should be used for decryption in an OTP encryptionsystem.

“Key offset” means a numerical value indicating the starting pointwithin an OTP key 2 when the key 2 is used in an encryption ordecryption procedure in an OTP encryption system.

“KK (KernelKey)” 6 means a reusable key that is used in an XOR operationin the manner described herein and for the purposes described herein.

“Obfuscate” means the use of a reusable key, such as an AK 4 or a KK 6,in an XOR operation. Obfuscation differs from encryption in that the keyused in the XOR operation is a reusable key, as opposed to a true OTPkey 2, which is not reusable.

“N-byte condition” means the requirement that no consecutive n bytes arerepeated within a KK 6, wherein n is a positive integer at least equalto 2.

“OTP (one time pad) encryption system” means an encryption system inwhich the encryption and decryption are performed by an XOR operation,and the encryption/decryption key (OTP key 2) is used just once and thendiscarded.

“OTP engine” 10 means a module, which may be implemented in anycombination of hardware, software, and/or firmware, that performs thefunctions of the OTP encryption system. When implemented in software,the module can be embodied in any computer-readable medium or media,such as computer memory, hard disks, floppy disks, optical disks, etc.

“OTP key” 2 is a key that is used for encryption and decryption in anOTP encryption system. The OTP key 2 is used just once and thendiscarded.

“Reusable key,” or “revolving key,” is a key that is used in an XORoperation and can be reused, by means of using adjacent portions of thekey in turn, and when the end of the key is encountered, recommencingwith the beginning of the key.

“Sliding algorithm” means an algorithm that applies a window having afixed number of bytes sequentially against an item being examined, suchas a key offset, and that performs a comparison at each sequential stepbetween the contents of the fixed length window and the item beingexamined.

“XOR (exclusive OR)” means a Boolean operation in which the combinationof a zero and a zero yields a zero; the combination of a one and a oneyields a zero; the combination of a zero and a one yields a one; and thecombination of a one and a zero yields a one.

AutoKey and KernelKey

The AutoKey 4 and KernelKey 6 that are described herein can be used inany OTP encryption system, such as the AlphaCipher Encryption Systemmanufactured by Vadium Technology, Inc. of Tacoma, Wash.

The basic operation of an OTP encryption system is illustrated in FIG.3. An OTP engine controlled by sender 50 obfuscates plaintext header 31using KernelKey 6 to produce ciphertext header 37, and encryptsplaintext body 32 using OTP key 2 to produce ciphertext body 38. Theciphertext header 37 and ciphertext body 38 are then sent over acommunications link 45 to recipient 60. Link 45 can be anycommunications link, such as the Internet, a modulated radio signal,semaphore, etc. An OTP engine 10 controlled by recipient 60 thende-obfuscates ciphertext header 37 using KernelKey 6 to recoverplaintext header 31, and decrypts ciphertext body 38 using OTP key 2 torecover plaintext body 32.

Both AutoKey 4 and KernelKey 6 comprise a truly random sequence ofbytes, similar to any truly random OTP key 2, but differ from an OTP key2 in that they are reusable. The length of AutoKey 4 and KernelKey 6 canbe any size; the longer they are, the more secure they become. NeitherAutoKey 4 nor KernelKey 6 detracts from the operation of the OTPencryption as performed by OTP key 2.

AutoKey 4 and KernelKey 6 are revolving keys, meaning that when the endof the key sequence is reached, the sequence starts over from thebeginning. The OTP engine 10 controlled by sender 50 keeps track of theportion of AK 4 or KK 6 that has been used, and therefore the portionthat should be used in the subsequent obfuscation performed by AK 4 orKK 6.

KK 6 has a special condition that it must meet: any consecutive n bytesin KK 6 must appear only once in that instance of KK 6, wherein n is apositive integer at least equal to 2. This condition is referred toherein as the “n-byte condition.” In a preferred embodiment, n=4. Thiscondition limits the length of KK 6; the larger the value of n, the lesssevere the length limitation. The reason for having this n-bytecondition on KK 6 is that it enables an engine 10 to find any n bytesequence easily and uniquely within KK 6, as described below. A qualityassurance computer program has been designed to pre-qualify a randomseries of bytes to meet this condition before it can be used as a KK 6.This quality assurance computer program truncates the series just beforethe n bytes repeat.

As illustrated in FIG. 2, KK 6 contains a floating header 7 for uniqueidentification purposes. This floating header 7 is positioned randomlywithin the random series of bytes used as KK 6. Floating header 7 isremoved by OTP engine 10 before KK 6 is used for its intendedobfuscation purposes. OTP engine 10 has been informed where floatingheader 7 is positioned within KK 6, and uses that information to extractthe floating header 7 from KK 6.

Floating header 7 comprises a GUID 8 and a section 9 comprising thefirst j bytes of AK 4, where j is a positive integer. In a preferredembodiment, j=16. GUID 8 uniquely identifies that KK 6. Section 9enables a unique linkage between

KK 6 and the AK 4 for that customer. Header 7 is exempt from the n-bytecondition, because header 7 is not considered to be part of KK 6 per se.

A first purpose of AK 4 is illustrated in FIG. 1, namely, theobfuscation of ciphertext 3 to produce AutoKeyed ciphertext 5 afterciphertext 3 has been produced by XORing plaintext 1 with OTP key 2. InFIG. 1, the horizontal bar within AutoKey 4 reminds the viewer thatAutoKey 4 is a repeating key. This obfuscation step is performed so thatthe decryption/de-obfuscation of the resulting AutoKeyed ciphertext 5requires the possession of both OTP key 2 and AutoKey 4. If the OTP key2 is stolen, the thief would still need AutoKey 4 to retrieve theplaintext 1. The thief could recover AutoKey 4, because AutoKey 4 is arepeating key, but it would require an extreme amount of work.

A second purpose of AK 4 is to tie a particular installation of the OTPencryption system to a unique set of OTP keys 2. This tying is achievedin that each OTP key 2 contains a floating header that is obfuscated byKK 6, and KK 6 is linked to AK 4 as described above. The effect of thistying is to prevent the unauthorized use of one customer's OTP keys 2 byanother customer who is using the same OTP encryption system.

The uses of KK 6 are more varied than those of AK 4. A first applicationof KK 6 is illustrated in FIG. 2. After the floating header 7 has beenremoved from KK 6 by engine 10, KK 6 can be used to obfuscate any andall byproducts of the OTP encryption, including, but not limited to, binfile 11, log file 12, and other byproducts 13. This obfuscation, whichis performed using an XOR procedure as indicated above, producesobfuscated bin file 21, obfuscated log file 22, and obfuscated otherbyproducts 23, respectively. A bin file 11 is a binary file produced bycertain OTP encryption systems, such as the AlphaCipher EncryptionSystem manufactured by Vadium Technology, Inc. of Tacoma, Wash., and isused for storing user preferences. A log file 12 is used by certain OTPencryption systems, such as the AlphaCiper Encruption Systemmanufactured by Vadium Technlogy, Inc. of Tacoma, Wash., and containsinformation as to the purpose or purposes of the OTP encryption. Otherbyproducts 13 can be any other byproducts of OTP encryption produced byany OTP encryption system. Obfuscating bin file 11, log file 12, andother byproducts 13 advantageously makes it harder for nefariousindividuals to eavesdrop on the encrypted communications.

Both AK 4 and KK 6 are used as constants within an organization,enterprise, or communications group. There is a limitation on thisconstancy, in that one or both of AK 4 or KK 6 may be lost, stolen, orcorrupted. In this case, AK 4 and KK 6 must be replaced or replenished.

Normally, there is one set of OTP keys 2, one AK 4, and one KK 6(collectively, “group”) per customer. It is possible for there to beseveral groups per customer, but this would prevent communications fromone group to another group. It is also possible for there to be one KK 6and several AKs 4 per customer, but again the subgroups within thecustomer having separate AKs 4 would not be able to communicate witheach other. In this latter embodiment, let us assume that there are mAKs, where m is a positive integer at least equal to 2. Then there are mKKs, all identical except for a different header 7. Each header 7 hasthe same GUID 8 but a different AK portion 9, so that all m of the AKsare pointed to by the set of m KKs. Then after the headers 7 arestripped from the KKs by engine 10, there is just one unique KK 6.

A second use of KK 6 is illustrated in FIG. 3. It is typical in an OTPencryption system for the plaintext 1 to consist of a plaintext body 32and a conjoined plaintext header 31. Body 32 contains the substantiveportion of the message 1 that is to be encrypted. Header 31, whichtypically appears at the beginning of plaintext 1, contains informationthat is useful in the decryption process. Such information can includethe identity of the intended recipient 60, the length of plaintext body32, the identity of an OTP key 2, and the key offset for said OTP key 2.Body 32 is encrypted by OTP key 2 using an XOR procedure, to produceciphertext body 38. Plaintext header 31 is obfuscated by KernelKey 6(after the floating header 7 has been removed from KK 6 by the sender'sengine 10), to produce ciphertext header 37. The reason that header 31is obfuscated is so that attackers will not be able to get access tosaid useful information.

In the present invention, the ciphertext header 37 is de-obfuscatedwithout the use of a key identifier or key offset, using a specialindexing system that takes advantage of the n-byte condition of the KK 6defined above. This indexing technique works as follows: plaintextheader 31 contains a unique n-byte index 33 that has been carved out ofKK 6. Index 33 is always in the same location within plaintext header31, and therefore each OTP engine 10 knows where to find index 33. Index33 is initially set to zero (all of its bits are zeroes). When plaintextheader 31 is obfuscated by KK 6, whatever is present within KK 6 at thesame relative location as index 33 is carried over into a correspondingKK portion 39 within ciphertext header 37, due to the very nature of theXOR operation, i.e., a zero XORed with any given bit yields that bit. Ina subsequent step, the OTP engine 10 of the recipient 60 goes to KKportion 39 to find the starting point of the portion 40 of KK 6 that wasused in the obfuscation and hence must be used in the de-obfuscation.(In any OTP process, the same portion of the key must be used for thedecryption (or de-obfuscation) as was used for the encryption (orobfuscation)). Because of the n-byte condition, we know that thisportion 40 of KK 6 is unique. Therefore, we know that the de-obfuscationwill be performed correctly. This de-obfuscation consists of the correctportion 40 of KK 6 being XORed with ciphertext header 37 to recoverplaintext header 31.

Variable Persistent Headers

The material herein pertaining to variable persistent headers appliesequally to KK headers 7 and plaintext headers 31, but for purposes ofease of illustration, the following discussion is directed to plaintextheaders 31. In order for header 31 to perform its various functions, atleast some of header 31 must persist (carry over from sender 50 torecipient 60). Traditionally, header 31 has been written in such a waythat it could be expanded should the need arise in the future to includeadditional data, such as, for example, biometric information pertainingto the holder of the OTP key set 2. This has traditionally been done byusing a size counter, wSize, as the first data member (field) of header31, indicating the length of header 31. This allowed for the definitionof a header 31 with known data members, with the possibility of addingmore data members to the end of the data structure comprising header 31as needed. This principle is illustrated in the following C languageexample:

struct {   WORD       wSize;   WORD       wDay;   WORD       wMonth;  WORD       wYear; } DATE_STRUCT

DATE_STRUCT defines storage for a date as it would be persisted on acomputer-readable medium of the recipient 60. The wSize member variableshould be preset to be equal to the size of DATE-STRUCT. If, in thefuture, the structure needed to be expanded while backward-supportingthe original DATE_STRUCT, a new structure with the first few datamembers being identical to DATE_STRUCT would have to be created, asshown below:

struct {   WORD       wSize;   WORD       wDay;   WORD       wMonth;  WORD       wYear;   WORD       wHour;   WORD       wMinute;   WORD      wSecond; } DATE_TIME_STRUCT

In this second example, the wSize member variable is preset to equal thesize of DATE_TIME_STRUCT. With these two data structures in place, theold data structure could be distinguished from the new data structure byexamining the value of the wSize member variable, as it would indicatewhether additional information was present. While this method has beenused frequently, it has drawbacks. Suppose, at a later date, the datastructure needed to be expanded to, for example, keep track of thenumber of days since January 1^(st) of the current year. The only placeto add this information would be at the end of the data structure, so athird DATE_TIME_STRUCT definition would be required. As another example,suppose that it was no longer necessary, at a later date, to keep trackof the year. Yet another data structure would be needed to eliminate thedata member wYear. These data structures are static and are thereforenearly impossible to change once they have been released to the public.This creates a housekeeping problem and wastes processing cycles.

From a security standpoint, there is another problem with the staticheaders of the prior art. Suppose that a 64-bit number is used as a keyoffset for OTP key 2, and that the key offset is stored within header31. When the OTP key 2 is used for the first time, the key offset willbe zero. Since a zero XORed with any value will return the XORed value,a sliding algorithm could be used by an attacker (who might interceptthe header as it traverses the communications link 45) to reliablydetect the section of the OTP key 2 that the rest of the informationaround the offset was encrypted with, thereby weakening security.

The present invention solves these problems caused by static headers byusing a header 31 where the first member variable (wFlags) consists of aset of flags that determine the contents of the rest of the header 31 asit is persisted. An example of a DATE_TIME_STRUCTURE using the presentinvention is:

struct {   WORD       wFlags;   WORD       wDay;   WORD       wMonth;  WORD       wYear;   WORD       wHour;   WORD       wMinute;   WORD      wSecond; } DATE_TIME_STRUCT

In the above DATE_TIME_STRUCT, wFlags is an arbitrary number of bitslong. Each bit of wFlags represents a different member variable in theremainder of the data structure. In an alternative embodiment, a givenbit within wFlags represents more than one data member, such as thecombination “wDay wMonth wYear.” The meaning of the bits within wFlagsis agreed to in advance by sender 50 and recipient 60 according to a setof rules (“convention” or “persist code”). Let us assume that theinitial value of wFlags is established by sender 50 as 110110. Let usfurther assume that the convention stipulates that these six bits withinwFlags refer to wDay, wMonth, wYear, wHour, wMinute, and wSecond,respectively. Thus, wFlags contains six individual one-bit flags. Flags1, 2, 4, and 5 are “set” (have a value of 1), and flags 3 and 6 are“cleared” (have a value of 0). This means that sender 50 wishes for thevalues of wDay, wMonth, wHour, and wMinute to persist, and for thevalues of wYear and wSecond to not persist. The reason for wanting topersist only certain variables and not others is to save processing timeand space. For example, sender 50 might have concluded that wYear is notimportant, because all of the communications are going to take place inthe same year, and that wSecond is not important, because the messages38 don't need to be tracked with that level of specificity. When therecovered persisted plaintext header 31 is read into a computer-readablemedium of recipient 60 for processing by OTP engine 10, the first fieldthat is read in is wFlags, which can then be used to read in the rest ofthe persisted header 31. Data is typically read in a word (i.e, twobytes) at a time. At the end of each word, a bit can be used to informrecipient's engine 10 as to whether additional portions of wFlags arepresent and therefore must be read in. In the case of a flag that hasbeen cleared, engine 10 will assign a default value to that particularmember variable. The defaults can be different for the different datamembers, according to the convention. For example, wYear can default tothe current year, and wSecond can default to zero. If a flag has beenset, the corresponding member variable is initialized with the value inthe persisted header 31.

In the above method, the order of member variables depends upon thepre-selected convention. For example, it is possible to persist wHourbefore wDay. To not persist a member variable, its flag is cleared; andto add a new member variable, it is not necessary to append it to theend of the data structure, since the convention is customizable. Theconvention can be changed after the OTP encryption system has beeninitially deployed, e.g., by sending a software patch to sender 50 andrecipient 60 changing the mapping of the flag bits to the data members.

When the OTP encryption system is first deployed, modules containing OTPkeys 2, OTP engines 10, and conventions pertaining to wFlags aredistributed to the prospective senders 50 and recipients 60. Thesemodules can be implemented in any combination of hardware, firmwareand/or software. When implemented in software, the modules can beembodied in any computable-readable medium or media, such as computermemory, hard disks, floppy disks, optical disks, etc. The initialconvention for wFlags can specify that a certain subset of bits withinwFlags is reserved for future use. The recipient's engine 10encountering the value of 1 in any of these bits will try to process thebit, but conclude it cannot do anything with it. Later, after a patchhas been sent out to sender 50 and recipient 60 amending the conventionto define the significance of this bit within wFlags, the recipient'sengine 10 will be able to process said bit.

A portion of header 31 is normally devoted to the key offset for OTP key2. Let us assume that the key offset is 64 bits long. During the earlystages of life of OTP key 2, the beginning portions of the key offsetwill be zero. Sending these initial zeroes over communications link 45wastes processing cycles, and presents a security risk, since anattacker could use a sliding algorithm against the key offset portion toundesirably obtain information as to which portion of KK 6 was used inthe obfuscation of the key offset portion of plaintext header 31. As asolution to this problem, one or more bits within wFlags can be devotedto indicating a portion of the key offset that is persisted. Forexample, flags within wFlags could be used to indicate whether 8 bits,16 bits, 32 bits, or 64 bits of the key offset are persisted.

In summary, the use of flags as described above allows great flexibilityin persisting information contained within header 31. The informationthat is persisted is determined by flags within wFlags, and the order inwhich the information is used is customizable for the particularapplication, and can be changed, as long as both the sender 50 and therecipient 60 are informed of the convention being used.

The above description is included to illustrate the operation of thepreferred embodiments and is not meant to limit the scope of theinvention. The scope of the invention is to be limited only by thefollowing claims. From the above discussion, many variations will beapparent to one skilled in the art that would yet be encompassed by thespirit and scope of the present invention.

What is claimed is:
 1. A computer-implemented method for strengtheningan OTP encryption system, said method comprising the steps of:encrypting plaintext with an OTP key in an XOR operation to produceciphertext; and obfuscating the ciphertext with an AutoKey in an XORoperation to produce AutoKeyed ciphertext, wherein the AutoKey is areusable key.
 2. The method of claim 1 wherein the AutoKey is uniquelylinked to a set of OTP keys.
 3. The method of claim 1 wherein theAutoKey is uniquely linked to a Kernel Key, wherein the KernelKey is areusable key.
 4. The method of claim 3 wherein the plaintext comprises aplaintext header and a plaintext body, said method further comprisingthe step of obfuscating the plaintext header with the KernelKey.
 5. Themethod of claim 3 further comprising the step of obfuscating byproductsof the OTP encryption with the KernelKey.
 6. A computer-implementedmethod for strengthening an OTP encryption system, said methodcomprising the steps of: obfuscating a plaintext header with a KernelKeyin an XOR operation to produce a ciphertext header, wherein: theKernelKey is a reusable key; and the plaintext header containsinformation useful in processing an associated plaintext body.
 7. Themethod of claim 6 wherein the information comprises items from the groupof items consisting of: identity of an intended recipient of theplaintext body; length of the plaintext body; identity of an OTP key;and key offset of said OTP key for use in decrypting the plaintext body.8. The method of claim 6 further comprising the step of de-obfuscatingthe ciphertext header, thereby recovering the plaintext header, bycombining the ciphertext header with the KernelKey in an XOR operationwithout using a key offset.
 9. The method of claim 8 wherein thede-obfuscating step is performed using an indexing technique comprising:selecting a preselected index location within the plaintext header; andfinding said index location within the KernelKey.
 10. The method ofclaim 6 wherein no consecutive n bytes are repeated within theKernelKey, where n is a positive integer at least equal to
 2. 11. Themethod of claim 6 wherein the KernelKey contains a randomly locatedheader comprising: a GUID; and a portion of an AutoKey, wherein theAutoKey is a reusable key.
 12. The method of claim 11 wherein theAutoKey is used to obfuscate ciphertext produced by the OTP encryptionsystem.
 13. A computer-readable set of data comprising a variablepersistent header for use in a computer-implemented communicationssystem, said header comprising: a plurality of fields containinginformation useful in processing a message associated with the header,said plurality of fields being located independently of the location ofthe message and not containing any synchronization information regardingthe location of the header vis-à-vis the location of the message;wherein: one of the fields comprises a set of flags indicating which ofsaid other fields are persisted from a sender of the message to arecipient of the message.
 14. The header of claim 13 wherein at leastone of the fields contains information pertaining to: identity of anintended recipient of the message; length of the message; identity of aone-time pad (OTP) key used to encrypt the message; or key offset ofsaid OTP key, given as a number of bits of a starting point within theOTP key, for use in decrypting the message.
 15. The header of claim 13wherein the header is contained within an obfuscation key that is usedto perform at least one of the following two tasks: obfuscate byproductsof encryption; obfuscate the header.
 16. The header of claim 13 whereinthere is a one-to-one mapping between at least one flag and one fieldother than the flag field.
 17. The header of claim 13 wherein there is aone-to-many mapping between at least one of the flags and at least twofields other than the flag field.
 18. The header of claim 13 whereinmeanings of the flags are agreed to by a sender of the message and arecipient of the message prior to the message being sent from the senderto the recipient.
 19. (The header of claim 18 wherein meanings of theflags can be changed after the message has been sent, and before asubsequent message is sent.
 20. At least one computer-readable mediumcontaining computer program instructions for strengthening an OTPencryption system, said computer program instructions performing thesteps of: encrypting plaintext with an OTP key in an XOR operation toproduce ciphertext; and obfuscating the ciphertext with an AutoKey in anXOR operation to produce AutoKeyed ciphertext, wherein the AutoKey is areusable key.
 21. At least one computer-readable medium containingcomputer program instructions for strengthening an OTP encryptionsystem, said computer program instructions performing the steps of:obfuscating a plaintext header with a KernelKey in an XOR operation toproduce a ciphertext header, wherein: the KernelKey is a reusable key;and the plaintext header contains information useful in processing anassociated plaintext body.